<?php
error_reporting(E_ALL);
// This page covers all project-related activities of the site.
// For each, it:
// -- describes the activity;
// -- briefly summarizes its current state; and
// -- gives a link to the particular page for that activity.
//
// (Leaves out non-project-related activities like:
// forums, documentation/faqs, development, admin.)

$relPath="./pinc/";
require_once $relPath."dpinit.php";
include_once($relPath.'dp_main.inc');
include_once($relPath.'mentorbanner.inc');
include_once($relPath.'progress_bar.inc');
include_once($relPath.'rounds.php');

$activity_hub = _("Activity Hub");

theme_header($activity_hub, true);

echo "
<div class='center'>
    <img src='$code_url/graphics/Activity_Hub.png'
                title='$activity_hub' alt='$activity_hub'>
</div>
<p>"
    .sprintf(_('Welcome to the %1$s Activity Hub. From this page
    you can view the phases of %1$s production. Follow the links
    to the specific areas of the site.'),$site_abbreviation)."
</p>\n";


// Site News
// show_news_for_page("HUB");

// =================================================================

echo "\n<hr>\n

<h1>General site description</h1>

<p>

The site is a clone of Distributed Proofreaders. If you know <a
href='http://pgdp.net'>Distributed Proofreaders</a> or <a
href='http://pgdpcanada.net'>Distributed Proofreaders Canada</a> this
is enough. Otherwise wait for us to complete the documentation, this
for now is just a test site... What follows highlights a few points
where we differ.

</p>


<h1>Activity descriptions</h1>

<h3>Providing Content</h3>

<a href='http://dp-test.dm.unipi.it/phpbb3/viewforum.php?f=29'>
How to provide new material for the site</a>

<h3>Project management</h3>

<a href='http://dp-test.dm.unipi.it/phpbb3/viewforum.php?f=30'>
How the Project Managers organize the proofreading activities</a>.


<h3> Proofreading activities</h3>

<p>The proofreading (and markup) is not organized (as in pgdp) in a
fixed number and tipology of rounds. It is organized in <i>tasks</i>,
structurally different, that can be combined in different sequences,
and can be repeated. Different pages can pass through different
sequences of tasks, and a different number of repetitions. Tasks are
currently organized in rounds: during a round, the same task is done
by all the pages at the same time (some pages may be excluded).</p>

<p>The task performed in each round is decided by the project manager,
that has full responsability; the site managers overview and evaluate
the performance of the PM by their results.</p>

<p>The tasks can be dynamically modified through a (global)
configuration file; adding new tasks is especially easy. The addition
of new tasks will be discussed in the <a href='http://dp-test.dm.unipi.it/phpbb3/viewforum.php?f=19'>Future Features forum</a>.</p>

<p>

Currently, the list consists of: <b>proofing</b>, <b>reproofing</b>,
<b>markup</b>, <b>check</b> and <b>special</b>. There are other
pseudo-tasks: <b>undefined</b>, <b>test</b> and <b>completed</b>.
Projects can be searched per task, and the task bar (the green bar at
the top) contains links to predefined searches. From any of the search
pages one can change the search.</p>


<h4>Proofing</h4>

<p> Proofing is the first manual pass after OCR and pre-processing.
hence it is the first round and cannot be repeated. It corresponds to
pgdp P1, but here it is reserved to proofreaders with experience on
the guidelines. </p>

<p> 

During proofing the WordCheck should be used, to help the PM to build
the project dictionaries. Knowing and following the guidelines is
essential, since the differences may be difficult to analize.
Differences between the other rounds are smaller, the PM will check
them, and might correct errors. The PM is not expected to check the
differences between the OCR and the first round, hence one should be
certain that no macroscopic error has been made. This is why beginners
are excluded.

</p>
<p>

<b>Follow the link ".link_to_task("proof")." (here or in the task bar)
to go to the projects available for the <i>proof</i> task. The task is
reserved to EXPERIENCED proofers. Beginners should start with ".link_to_task("reproof")."</b> </p>

<p>As all the other tasks this is optional; a PM may decide to start
with reproofing if the pre-processing has been sufficiently deep (for
example, if the project has been already proofread, e.g. at another
site like DP-EU).</p>

<h4>Reproofing</h4>

<p>

<b>This is where beginners should start.</b> Reproofing corresponds to
P2 (and P3) at pgdp; the quality control, instead of being assured by
qualification, is assured by statistical analysis, by diff control,
and by selective task repetition per page. Currently some of the tools
are still missing, but are replaced by offline tools and manual diff
inspection.

</p>
<p>

<b>Follow the link ".link_to_task("reproof")." (here or in the task
bar) to go to the projects available for the <i>reproof</i> task.</b>
</p>

<h4>Markup</h4>

<p>

Markup corresponds to F1 at pgdp. It can currently be repeated only
through project duplication: a clone is created with the text coming
from reproofing, and the two are run in parallel. The results are
merged offline, and the result of the merge inserted in the next round
of both, to provide feedback. Three or more rounds in parallel are
also possible.

</p>
<p>

<b>Follow the link ".link_to_task("markup")." (here or in the task
bar) to go to the projects available for the <i>markup</i> task.</b>
</p>

<h4>Check</h4>

Corresponds to F2 at pgdp, and is optional, at the discretion of the PM. 


</p>
<p>

<b>Follow the link ".link_to_task("check")." (here or in the task bar)
to go to the projects available for the <i>check</i> task.</b> </p>

<h4>Special</h4>

<p> This heading collects different tasks, that require special
habilities (e.g. greek, index pages or other markup-heavy pages, etc).
that will be detailed in the project comments.

We expect in future to have a finer subdivision of the <i>special</i>
task.

</p>
<p>

<b>Follow the link ".link_to_task("special")." (here or in the task
bar) to go to the projects available for the <i>special</i> task.</b>
</p>

<h4>Pseudo-tasks</h4>

<p>

".link_to_task("undefined")." is for projects that are not yet ready
to start, ".link_to_task("completed")." is for projects that have
ended the page-by-page procedures, ".link_to_task("test")." is for
projects that are not proofread but are used to test some code
features that are otherwise hard to test.

</p>


<h2>Guidelines</h2>

We don't have yet updated guidelines, so we take 
<a href='http://www.pgdp.net/c/faq/proofreading_guidelines.php'>
pgdp proofreading</a> and 
<a href='http://www.pgdp.net/c/faq/document.php'>formatting</a>
 guidelines as a
starting point and reference, and just list the main differences. You
can refer also to 
<a href='http://www.pgdpcanada.net/wiki/index.php/FAQ_Proofreading_Guidelines'>
pgdpcanada proofreeading</a> and
<a href='http://www.pgdpcanada.net/wiki/index.php/Formatting_Guidelines'>
formatting</a>  guidelines, since we go in the same
direction, just going a bit further.

These updates are in test, hence still subject to discussion, and as
usual the PM can override any guideline.


<h3>
Unicode
</h3>

<p>


Our code allows entering any unicode character, so pgdp notations like
['s] for ś or [Greek: alpha] for ἄλφα are no longer needed, just use
the proper characters. 
We have special rules for whitespace, dashes, quotes.
</p>

<p>

The different methods to enter non-ASCII characters include pickers
and digraphs (combinations character-backspace-character). And of
course one can use system support like alternative keyboards or
external chacater pickers. 

</p>


<h4>
Whitespace
</h4>

<p>

Use ASCII space (inserted by the space bar) for every type of space.
The different types of spaces cannot be distinguished easily,
especially in a proportional font, and will be handled in
post-processing. Do not use zero-width characters.


</p>

<h4>
Dashes
</h4>

<p>
There are different types of dash characters, that appear different in a proportional font, but look the same in a fixed size font; e.g. - ‐ ‑ ‒ – — ― − ;
the first is the usual hyphen-minus found in all keyboards, the last is the minus-sign, Unicode 2212. In a fixed-width font they are difficult to distinguish.
</p>
<p>
We use one, two or four dash characters as at pgdp, with the following differences:
</p>

<p> 

- we do not remove the spaces around dashes: if there is a space (of
  any size) keep it. Usually, only English (and not always) uses
  dashes without spaces.<br/>

- Since hyphen-minus and minus sign are interpreted differently by our
  spell-checker, (hyphen-minus and other dashes are handled as letters
  unless they are at the start of a word, minus-sign is never part of
  a word) use two minus-sign when a dash follows a letter without a
  space, and hyphen-minus when the dash is a replacement for a letter
  (for example in Mr. D----, or in partly censored words). Otherwise
  we use indifferently hyphen-minus. Otherwise it is indifferent which
  character is used. Do not bother looking for other dashes, just use
  the proper number of characters. Using the proper characters will be
  done in post-processing.<br/>

- the minus sign is present in the + picker (it is the last character)
  and is available as -- digraph (- backspace -).

</p>

<h4>
Quotes
</h4>

<p> There are different types of quotes, use the proper type
reproducing the image. There are buttons, pickers, digraphs to
introduce several of the quote types. Our quote buttons operate on a
selection putting quotes around it, erasing a quotation mark (the
ascii quote) if there is one at the boundary. Use properly curled
quotes for single quotes, and preserve apostrophe (the standard ASCII
single quote ') for apostrophe. </p>



<h3>
Ellipses
</h3>

<p>
Preserve the number and spacing of the periods in the quotes. Since often it is unclear if there is a space or not between the periods, use a space only if it is clearly a space. Do not use the Unicode ellipsis character ( … ).
</p>

<h3>
Contractions (spacing apostrophes)
</h3>

<p> It is often not clear if there is a space or not near an
apostrophe. Use each language's rules concerning the spacing.


</p>

<h3>
Notes, comments and tweets; *-, -* and *_.
</h3>

<p>
- Use *- ( to*-day instead of to-*day) for undecided end-of-line hyphens

<br/>

- use -* for word parts split at the end of page (like pgdp)

<br/>

- use *_ instead of just * before the second part of a word at the top of
  the page. 

<br/>

Hence for example for-* (new page)  *_ward

</p>
<p>

The [**] button works slightly differently from pgdp: if you select
'wodr' and hit the key, the result is wodr[** wodr] that you can then
edit as wodr[** word]. Use this format (no need of further 'typo' or
other indications).

</p>

<p> For more complex notes, <i>tweets</i> will be introduced. i.e. a
space for notes external to the page; for now, put these as notes at
the end of the page, in the format [## text of the tweet]. This will
allow to convert easily to the tweet format when it will be supported.
This can be used also to remark the existence of features on the page
that you might have not completed correctly, e.g. [## check greek]. 
</p>
";

echo "
</dl>
</div>\n";

theme_footer();
// vim: sw=4 ts=4 expandtab
?>
